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Early Codes 


During the early days of data processing and telecommunications, a 
number of codes were in use or proposed for use: 

a) CCITT #2, a 58-character, shifted 6-bit code, used nationally and 
internationally on telegraph lines. 

b) FIELD AT A [3.1, 3.2, 3.3]: a 7-bit code developed by the United 
States Army for military communications systems. 

c) BCDIC [3.4]: a 48-character, 12-row code (initially unnamed) used 
on computing systems. This code was eventually expanded to be a 
64-character, 6-bit code and 12-row card code. 

d) The Stretch code: a 120-character, 8-bit code used on the Stretch 
computer (the IBM 7030) [3.5, 3.6], 

e) IPC, Information Processing Code [3.7]: a 128-character, 8-bit code 
developed by the United States Air Force proposed to be used for 
information processing and information interchange. 

f) A 64-character, 6-bit code proposed by H. S. Bright in 1959 [3.8]. 

g) A 256-character card code proposed by R. W. Berner in 1959 [3.9], 

h) 4-out-of-8 code: a 70-character, 8-bit data transmission code. 

These early codes manifested some of the characteristics of coded charac- 
ter sets described in Chapter 2. Some of these characteristics would be 
carried forward and incorporated into modern codes. It should not be 
supposed that these early codes have disappeared from the data proces- 
sing scene. Products and systems implementing these codes (with the 
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exception of IPC) are still in common use. Figure 3.1 shows the codes and 
their characteristics. 

CCITT Fiel- Bright Berner 4-out- 

#2 data BCDIC Stretch IPC Proposal Proposal of-8 

Shifted code yes 



Space equals 
no punches 


Collapse logic 


Fig. 3.1 Characteristics of early codes 


3.1 CCITT #2 

CCITT #2 was, and is, a 58-character, shifted 6-bit code, standardized as 
an international telegraph code in 1931 by the Comite Consultatif Inter- 
national Telegraphique et Telephonique (see Fig. 3.2). 
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Fig. 3.2 CCITT # 2 


Figure 3.1 reveals that CCITT ^2 manifests few of the characteris- 
tics of the other codes, characteristics deemed desirable for data proces- 
sing codes. The numerics are not BCD, nor contiguous, nor in numeric 
sequence; the alphabetics are not in alphabetic sequence, and so on. But 
it should be realized that CCITT # 2 was developed as a telegraph code, 
and characteristics desirable for a data processing code have little impor- 
tance for a telegraph code. 

CCITT #2 did manifest a characteristic that is quite necessary for 
data processing codes and for telecommunication codes. Three code 
positions were reserved for “national use.” This recognizes a characteris- 
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tic of certain European languages (German, Danish, Swedish, Finnish, 
Norwegian, for example) which is that such languages have three letters 
in addition to the 26 alphabetics of English-speaking languages (see Table 
3.1). Such letters are called diacritical letters, or diacritics. 

TABLE 3.1 Diacritical Letters 

German A 6 U 

Danish/Norwegian IE 0 A 

Swedish/Finnish A 6 U 


Clearly, telegraph devices operating within national boundaries of ! 
countries whose languages require 29 alphabetics would have to have the 
capability of sending and receiving all 29 letters. The telegraph code, ■ 
then, must have code positions available for 29 letters and CCITT #1 
does. 

In English-speaking countries, such code positions could be used to 
represent other symbols. In the U.S.A., on Western Union telegraph ; 
devices, for example, the symbols # $ and & were provided in these three 
code positions. 

1 

3.2 F1ELDATA 

FIELD ATA was a 7-bit plus parity code developed by the United States . 
Army for use on military data communications lines. It became a U.S. 
Military Standard in 1960 (see Fig. 3.3). 

It is to be noted that although there are 128 code positions in the 
7-bit code, only 64 were defined, consisting of 9 control functions and 55 j 
graphic characters. The controls are of the kind required by rather simple, ; 
typewriter-like devices — Space, Upper Case, Lower Case, Line Feed, Car- 1 
riage Return, and so on. The 64 undefined code positions were intended to J 
be assigned to the more complex kinds of functions necessary for inter- | 
connection and control of data transmission networks. 

As it turned out, three different communications systems were de- 1 
veloped implementing FIELD ATA, and each of these three systems used | 
different control functions in the “not defined” portion of the code j 
table — different in the sense of technical definition and different in the 1 
sense of the number of control functions. It was found that'because of | 
these different control functions interconnection of these three communi- | 
cation systems, and intercommunication between them, was difficult or j 
impossible. 
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Fig. 3.3 FIELDATA 

A valuable lesson was learned here. For various reasons, it may be 
desirable not to complete the assignment of meanings to all code posi- 
tions of a code table initially. For example, the American National 
Standard Code for Information Interchange (ASCII), when first standar- 
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dized in 1963, left some 28 code positions without assigned meanings. 
And when the extended BCD Interchange Code (EBCDIC) was adopted 
as an internal standard by IBM in 1964, of the 256 available code 
positions, only 108 code positions had assigned meanings. Indeed, at this 
time (almost a decade later) there are still many code positions in 
EBCDIC with unassigned meanings. However, in the administration of 
these standards, ASCII and EBCDIC, implementors were advised to 
provide implementations which did not assign meanings to those code 
positions without already assigned meaning. These code positions were 
reserved for future standardization. For FIELDATA, implementors pro- 
vided implementations with their own local meanings for those code 
positions not initially assigned. The result was inter-implementation con- 
fusion. The disciplined administration of ASCII and EBCDIC prevented 
such confusion. This point of administrative discipline will be discussed 
below with IPC, Information Processing Code. 


3.3 BCDIC 

With modern codes, such as ASCII and EBCDIC, it is common practice 
to provide implementations which use not the full repertoires of the codes 
but subsets, subsetted by graphics, or by controls, or by both. By contrast, 
the code that came to be called the BCD Interchange Code (BCDIC) 
evolved from a smaller repertoire to a code with a complete repertoire. 
(The evolution of BCDIC is described in detail in the next two chapters.) 

The punched card code devised by Dr. Herman Hollerith at the end 
of the nineteenth century was a 12-character code consisting of the 10 
numerics, 0 through 9, and two control characters in what are now the 
12-row and the 11-row of the card. In the statistical applications of the 
United States Census— for which Dr. Hollerith devised the punched 
car d — these control punches served many purposes. When punched cards 
came to be used in accounting applications, the 11-punch came to be used 
to represent a credit balance (mathematicians would call it a negative 
number). 

Somewhere around 1932, the punched card code was expanded to 
include 26 alphabetics and three special symbols — minus sign, asterisk, 
and ampersand. The minus sign had replaced the credit symbol, asterisk 
was used for check protection, and ampersand was used in name-and- 
address applications (Mr. & Mrs. J. L. Smith, for example). The punched 
card code for these 39 graphics and space is shown in Fig. 3.4. 

During the 1950s, the advent of computers such as the IBM 702, 
705, and 1401 saw the expansion of BCDIC into 47 graphics, and also 
the development of a 6-bit code to represent these graphics. With one 
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Fig. 3.4 BCDIC, 40-character card code 


exception, the 11 special symbols served an obvious purpose in one or 
another commercial application: 

.'$,#%-&*/ H 

The exception was the special symbol, tt (lozenge). Because the lozenge 
appeared on printer chains, it was put to various uses; for example, to 
indicate, in the margin of a tabulation, final totals as contrasted to 
subtotals. 

The 48-character BCDIC is shown in Fig. 3.5. 


3.4 THE STRETCH CODE 

In 1961, the IBM 7030 was delivered to the Los Alamos Scientific 
Laboratory. This computer was developed under “Project Stretch,” and 
this name was popularly used to describe this computer. 
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Fig. 3.5 BCDIC, 48-character code 


There were many technological innovations in Stretch. Architectur- 
ally, its main innovation was that it had an 8-bit architecture, as con-., 
trasted with the 6-bit, or 6-bit oriented, architectures of other computers 
of the time. With an 8-bit architecture, a 256-character code is possible. 
In fact, the designers of Stretch chose to provide a 120-character set that, 
apart from its size (most computer character sets of that day were 
48-character sets), had some interesting innovations. 

The codes for contemporary computers of that time had evolved 
from earlier beginnings and compatibility was the primary design criter- 
ion. The designers of the Stretch code, E. G. Law, H. J. Smith, Jr., F. A. 
Williams, W. Buchholz, and R. W. Berner, did not perceive compatibility 
with contemporary codes to be a primary criterion. Instead, they them-; 
selves set some criteria that they felt were reasonable for a code. The 
criteria were in regard to the size and structure of the set. The criteria are 
first stated, and then some of them are discussed. 
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3.4.1 Size 

Criterion 1. The set should contain the contemporary 48-graphic set 

found on IBM computers: 

■ Space 

■ 26 alphabetics (upper case) 

■ 10 numerics 

m 11 specials . ’ &%(-/,$ # ct 

Criterion 2. The set should contain the following graphics: 

■ 26 lower case alphabetics 

■ The more important punctuation symbols found on office 
typewriters 

a Enough mathematical and logical symbols to satisfy the needs of such 
programming languages as ALGOL. (The total ALGOL set was well 
over 100 symbols.) 


3.4.2 Structure 

Criterion 3. Certain subsets, such as the contemporary 48-character set 
for high-speed chain printer printing and an 88-graphic set for a typewri- 
ter, should be simply derivable. 

Criterion 4. The graphics should be blocked contiguously by function; 
viz., the specials should be in a contiguous block, the alphabetics should 
be in a contiguous block, the numerics should be in a contiguous block, 
and so on. 

Criterion 5. The binary sequence of the bit patterns representing the 
graphics should match whatever collating sequence was prescribed for the 
graphics. 

Criterion 6. The 48 graphics of contemporary IBM computer codes 
should have, in the Stretch code, the same collating sequence, or should 
be embedded in the same relative collating sequence, as the contempor- 
ary collating sequence, namely, Space, then the specials . K &$*■-/ , 
% #@then the alphabetics, then the numerics. 

Criterion 7. The upper and lower case alphabetics should be inter- 
leaved. 

Criterion 8. There should be unique bit patterns for each unique 
i graphic; that is, duals would not be permitted. 
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70 Early Codes 

As well as these criteria, there was a constraint on the size of the set. The 
theoretical constraint was a maximum of 256 characters, since the byte 
size of Stretch was to be 8 bits. But there was a more pragmatic constraint 
due to the printer to be used with Stretch, the chain printer. The chain 
printer, due to its design geometry, had 240 printing positions; so this was 
clearly the maximum possible set size. However, as a practical considera- 
tion, the larger the set size, the lower is the printing speed of the chain 
printer. The actual choice was 120 characters. This was a matter of 
judgment; it was decided that this increment over existing sets would be 
sufficiently large to justify a departure from contemporary codes and 
would not include many characters of only marginal value. Also, the set 
size of 120, in terms of the 240 printing positions of the chain printer, 1 
meant that each symbol could appear twice on the chain, yielding a not 
unreasonable printing speed. 

The actual character set and the coded representation is shown m 
Fig. 3.6. It is evident from inspection of the code that not all criteria were ■ 
met. In fact, the criteria were somewhat mutually conflicting, and some 
trade-offs were necessary. 
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Fig. 3.6 Stretch. 120-character set 






3.4 


The Stretch Code 71 



>n f : size of the set. The 
haracters, since the byte 
nore pragmatic constraint 
ch r printer. The chain 
tin fe positions; so this was 
. as a practical considera- 
inti ; speed of the chain 
;. ' is was a matter of 
er existing sets would be 
xm‘- mporary codes and 
gin value. Also, the set 
ons of the chain printer, 
the chain, yielding a not 

presentation is shown in 
that not all criteria were 
Jly onflicting, and some 




Comment on Criterion 6 

The contemporary collating sequence for the 47 graphics provided on 
contemporary computers was not achieved. In order to provide an 
89-graphic subset and a 49-graphic subset derivable by simple logic 
(Criterion 3), the specials had to be positioned somewhat arbitrarily 
(see Figs. 3.7 and 3.8), and this was deemed more advisable than the 
collating-sequence criterion. Nine of the contemporary specials did col- 
late low to alphabetics and numerics, although even these were not, 
within themselves, in the contemporary collating sequence. It was felt that 
the new sequence would be quite usable and that it would be necessary 
only rarely to resort a file in the transition to the Stretch code. And it is 
always possible to translate codes to obtain any desired sequence. 

Comment on Criterion 3. 

As can be seen in Figs. 3.7 and 3.8, both the 49-graphic subset and 
89-graphic subset were simply derivable from the 120-graphic code. 
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Fig. 3.8 Stretch, 89-character set 


1 


Note that the 49-graphic set included the contemporary 48-graphi 
set (see Criterion 1) and additionally had the graphic apostrophe o 
single quote. The provision of a 48-graphic-plus-Space set fitted neatl 
into the geometry of the 240-printing-position chain printer: 5 x 48 = 24 
Each graphic was provided in 5 printing positions, yielding very respect 
ble printing speeds. 

Note that the 49-graphic set is not entirely a subset of the 89-graphi 
set. Note also that it was found not practical to retain the upper- anc 
lower-case relationships of punctuation and other special symbols coml 
monly found on typewriter keyboards. (There was no single conventio 
anyway, and typists were accustomed to finding differences in this area.) 

Comment of Criterion 1 

The benefit of interleaving upper- and lower-case alphabetics is dubiou 
(For a fuller discussion of this point, see Chapter 25, Contiguous, Non : 
contiguous, and Interleaved Alphabets.) However, once it is decided t< 
interleave the alphabets, as was done in the Stretch code, a furth 
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decision is necessary: Which alphabetic should precede within the pair, 
the upper-case or the lower-case? The designers of this code had ob- 
served that no real precedent existed for the relative position within the 
code. But the choice had to be made. They chose that lower case should 
precede upper case within the pair, for reasons not known to the author. 

It is interesting to note that had they made the other choice, so that 
“A” had bit pattern 0010 1100 and “a” had bit pattern 0010 1101, for 
example, the derivation of the 49-character subset (Fig. 3.7) from the 
120-character set (Fig. 3.6) would have been logically simpler. Observe 
that in Fig. 3.7 the specials chosen alternate in code position with those 
not chosen and the same is true for the alphabetics and the numerics. 
However, two code positions intervene between the last special and the 
first alphabetic, and no code position intervenes between the last alphabe- 
tic and the first numeric. The logical equations to describe the choice of 
code positions are somewhat complex because of the double gap and the 
null gap. Had the opposite choice been made in assigning upper- and 
lower-case alphabetics, both anomalies would disapppear, and the logical 
equations would have been quite simple. It should also be noted that this 
latter choice would not have affected the derivability of the 89-character 
subset, since the 52 alphabetics would still occupy the same contiguous 52 
code positions. 

It is interesting that in the design of IPC, Information Processing 
Code, described below, where the designers also chose to interleave the 
upper- and lower-case alphabetics, the decision was that upper-case 
should precede lower-case alphabetics within the pair. 

In conjunction with the Stretch bit code, there was a punched card 
code. The bits of the code were named B0, Bl, B2, ...,B7, from 
high-order to low-order significance within the byte. A parity bit, odd 
parity, named Bp was also punched. The card code (see Fig. 3.9) was a 
binary card code, specified by the following algorithm: 

Card Row Code Bit 
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Fig. 3.9 Cards punched with extended character code 

In order to distinguish cards with this binary punching from cards 
punched with the conventional Hollerith card code, binary punched cards 
had 12-holes and 11-holes punched in column 1. Within an application, 
conventional Hollerith card code punching could be used in the right end 
of such cards, as shown in Fig. 3.9. The Space character, having no bits in 
the code, would nevertheless have a parity bit punched in row 1. 
However, skipped fields would have no punches, as can be seen in the 
lower card in Fig. 3.9. 
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As in discussed in Chapter 16, “Decimal ASCII,” the structural 
strength of a card punched in binary came under serious question 
particularly if most of the data was numeric (which would lead to one or 
more rows being laced because of the zone bits in the representation of 
the numerics). It should be noted that the question of binary card coding 
in the Decimal ASCII debate was considered in the environment of an 
individual card, mailed to a human, carried by the human in a pocket in 
varying conditions of humidity, temperature, and abuse, and subsequently 
required to be further processed in card equipment. By contrast, the 
normal environment for a Stretch card was much more protective — 
oenerally a deck of cards, handled with reasonable care in a machine 
room environment. The binary card discussed in Chapter 16 was expected 
to be subjected to structural stress, the Stretch card was not. 

3.5 IPC 

IPC, Information Processing Code, was developed by Edward Morenoff, 
John B. McLean, and Lt. Lawrence Odell in 1964. It was intended as an 
information manipulation-oriented character set with associated binary 
code representation. The author does not know if it was actually im- 
plemented, but it has some interesting aspects. The design criteria were 
somewhat similar to those of the Stretch code. 

Criterion 1. The set should contain the following graphics: 

■ Upper- and lower-case alphabetics 

■ Numerics 

* The more important punctuation symbols found on office typewriters 

■ 91 '" 

* 9 * 9 

■ Special symbols peculiar to user operations. 

Criterion 2. Certain subsets, 7-bit, 6-bit, 5-bit, 4-bit, should be easily 
derivable. 

Criterion 3. Code positions should be provided that would be dedicated 
to local interpretation. 

IPC was an 8-bit code. However, only 128 characters were specified, 
and the use of the 8th bit was deliberately left undefined for specification 
in local environments on the basis of particular applications. For example, 
the 8th bit might be used as a parity bit to increase the reliability of data 
transmission. Or it might be used to indicate that some special signifi- 
cance should be attached to a particular character, such as being part of a 
“keyword,” or a part of a highly sensitive piece of information. Since the 
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TABLE 3.2. IPC, special graphics and controls 


( 

Left parenthesis 

n 

Quotes 

I 

Exclamation 

» 

Apostrophe 

9 

Question 

$ 

Dollars 

# 

Numbers 

* 

Cents 

o 

Degrees 

V 

Summation 

/ 

Slash 

1/4 

One quarter 


Asterisk 

< 

Equal or less 

) 

Right parenthesis 

1/2 

One half 


Period 

> 

Equal or greater 

> 

Comma 

3/4 Three fourths 

7 T 

Pi 

GO 

Infinite 

— 

Minus 

1 

Arrow (down) 

C O 

Omega 

d 

Theta 

+ 

Plus 

t 

Arrow (up) 

a 

Alpha 

<t> 

Phi 

X 

Multiply 

—> 

Arrow (right) 

p 

Beta 

K 

Kappa 

■j* 

Divide 

<— 

Arrow (left) 

= 

Equals 

] 

Right bracket 

- 

Dash 

[ 

Left bracket 

V 

Square root 

3 

Cubed 

J 

Integral 

2 

Squared 


Colon 

1 

Escape code # 2 

@ 

Semicolon 

E 

Escape code #1 

At 

Bk Blank key #\ 

X 

Box —x 

Q 

Center dot 

Control #\ 


3re ntation (see Fig. 
tracers are given in 

per and lower-case 
ie, decision had to 


be made on which should precede within the pair. The IPC designers 
chose that upper case should precede lower case, so that proper nouns 
would collate ahead of common nouns. For example, Jack 

0011110, 0001101, 0010001, 0100001 
collates ahead of jack 

0011111 , 0001101 , 0010001 , 0100001 . 

The most interesting aspect of IPC is the design philosphy of Criter- 
ion 3— local interpretation. In the design of ASCII, described in later 
chapters, a set of control characters was defined to include several types 
of mput/output equipments, thus forming a general set, which must of 
necessity have more characters than the set contained in IPC that is 
interpreted differently for different equipments. 
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Contained within the set were four positions with unassigned meaning 
and corresponding to two “blank keys” on a keyboard. Thus there are 
two upper-case and two lower-case characters available for local interpre- 
tation. 

As stated under Criterion 3, subsets should be simply derivable. By 
dropping the high-order bit, a 6-bit subset is derived (Fig. 3.11). It 
contains numerics, upper- and lower-case alphabetics, Space, and the 
reserved code for local use. 


1 



m 

IB 

2 

3 

4 

5 

6 

7 

[ggjjj 

I 

H 

11 

11 

11 

IH 

IH 

IH 

IH 

| KCEEI 

IBB 

ibb 


IBI 

IBB 

nt 

i^b 

IBB 

0 

0 0 0 0 

n 

! 

K 

IH 

IH 

IH 

IH 


1 

0 0 0 1 

■ 

H 

II 

IH 

IH 

H 



2 

0 0 10 



IH 

IH 

H 

IH 



3 

0 0 11 

■ 

H 

IH 

H 


IH 



4 

0 10 0 


E 

M 



H 



5 

0 10 1 

■ 

■ 

H 

H 


H 



6 

0 110 




H 


H 



7 


■ 

1 

9 

H 


H 



8 



Hi 

H 



H 



9 


■ 

H 

H 

H 


Hi 



10 

10 10 

SP 

H 

P 

HI 


HI 





1 

H 

Si 

HI 


H 



B 


HI 

H 

Q 

HI 


H 


■I 

B 


HI 

H 

HI 

HI 


HI 


■I 

D 

1110 

B 

J | 

R 

HI 


HI 


■I 

□ 

mm 

II 

II 

■1 

HI 


HI 


■I 


Fig. 3.12 IPC, 5-bit subset 
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- - OR 
~ - AND 


u - Up Shift 
b - Space 


e - End of line, end of card, d - Down Shift 
or carriage return n - Null 


Fig. 3.14 Early 64-character proposal 


3.6 AN EARLY 64-CHARACTER CODE PROPOSAL 

In a Letter to the Editor, Communications of the ACM, 1959 May, H. S. 
Bright proposed a 64-character, 6-bit code. At that time, most printing 
and keypunching equipment was limited to 47 or 48 characters. The 
proposed code is shown in Fig. 3.14. 

It is structurally compatible with BCDIC (Fig. 3.5). The sequence of 
the code table columns containing the alphabetics has been reversed from 
BCDIC, so that the alphabetics are in relative collating sequence. Oddly 
enough, Space, which traditionally collates low to numerics, alphabetics, 
and specials, was not assigned to the bit pattern 000000. This was 
undoubtedly done so that zero could be given bit pattern 000000, so that 
the numerics would be in relative collating sequence. 
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3.7 AN EARLY 256-CHARACTER CARD CODE PROPOSAL 

In 1959 September, R. W. Berner proposed a “Generalized Card Cod 
for 256 Characters.” At that time, as stated previously, characte 
sets provided on printers and keypunches were mainly limited to 48 

As described earlier in this chapter, Project Stretch was started ii 
IBM in 1954. It was a project to develop a bigger and faster compute) 
than any then in the field. One decision made was that Stretch woulc 
have an 8-bit architecture, in contrast with most computers of that time 
which had a 6-bit, or 6-bit oriented, architecture. 

R. W. Berner, therefore, foresaw the need for a 256-character card 
code. The card code he proposed was not, in fact, adopted by Stretch bui 
it has many ingenious aspects. The card code set had criteria for design. 

Criterion 1. The new set must contain the existing 48-character set as " 
subset, with exactly the same graphic-to-hole-pattern relationship. 

Criterion 2. The new set should contain at least 256 combinations an 
be expansible beyond this number. 

Criterion 3. Meanings need not initially be assigned to all hole patterns 

Criterion 4. The hole patterns should be structured, if possible, o 
existing zone punch/digit punch hole patterns. 

Criterion 5. Hole patterns should be constructible and reproducible o 
existing keypunches (for example, the 024 or 026). 

Criterion 6. There should be no duals. 

Criterion 7. ALGOL characters should be included. 

Criterion 8, Characters not in the current IBM set or ALGOL set, bu 
used by other manufacturers, should be included. 

Criterion 9. There should be a simple relationship between upper- am 
lower-case alphabetic hole patterns. 

There are 322 possible combinations of no more than four punche 
per card column, when no more than two may be zones (12, 11, 0) and nq 
more than two may be digits (1 through 9). Figure 3.15 shows the 256 o 
these that remain when all combinations with two-digit punches contain „ 
ing a 1-punch and ten other combinations are excluded. The figure also/ 
shows assignment of both old and new graphics to hole patterns, t 
An ingenious aspect of this proposal is that each of the hole patterns; 
may be constructed in a card column by superimposing the hole patterns 
for two of the alphameric characters in current use. These two characters' 
are chosen for their mnemonic content. Thus [ is represented mnemoni 
cally by LB (for Left Bracket) and is constructed of the hole pattern ll-3, ! 
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HF 

IF or if OR 


UW do DQ 
dbl pr DP 
% " DQ * 

\ RD 
v EO 

! EP 

= EQ 
_ return RE I 
go to GO 

""for FR - 


^ 1 ‘ 1 1 L* L2S1 II I 1 array I RY U [ IY 1 

Fig. 3.15 A 256-character card code proposal m Mnemonic 

f°r L and 12-2, for B. Therefore, the hole pattern chosen to represent 
Left Bracket is 12-11-2-3. Fig. 3.16 shows the derivation of the 
mnemonics chosen for new graphics. 

Some ALGOL words were arbitrarily assigned to single graphics: 

If is assigned to ? 

BEGIN is assigned to { 

END is assigned to } 

INTEGER is assigned to # 








84 Early Codes 


Graphic 

monic 

Symbolizing 

Graphic 

monic 

Symbolizing 

+ 

+ 





X 




SC 

SemiColon 

/ 

/ 



CO 

COIon 

\ 

RD 

Reverse Divide 

j 

EP 

Exclamation Point 

+ 

PM 

Plus or Minus 

' 

QU 

QUote 


SQ 

SQuare root 

" 

DQ 

Double Quote 

= 

EQ 

EQuals 

:= 

LS 

Left Substitution 


UN 

UNequals 

=: 

RS 

Right Substitution 

> 

GR 

GreateR 

10 

TN 

base TeN 

> 

GE 

Greater or Equal 

] 

RB 

Right Bracket 

< 

LE 

Lesser or Equal 

i 

LP 

Left Parenthesis 

< 

LR 

LesseR 

i 

RP 

Right Parenthesis 


TD 

TilDe 

t 

LB 

Left Bracket 

1 

NO 

NOt 

t 

UW 

Up arroW 

V 

LO 

Logical Or 

i 

DW 

Down arroW 

A 

LM 

Logical Multiply 

<- 

LW 

Left arroW 

V 

EO 

Exclusive Or 

- 

RW 

Right arroW 

= 

ID 

IDentical to 

{ 

BG 

BeGin 




> 

ND 

eND 

i 

CE 

CEnts 

1 

VR 

VeRtical 

% 

QR 

one QuarteR 

A 

TR 

TRiangle 

y* 

HF 

one HaLf 

□ 

BX 

BoX 

cr 

CR 

CRedit 

O 

Cl 

Circle 


DG 

DeGree 


US 

Underscore 

oo 

IY 

InfinitY 

procedure 

PC 

Procedure 

go to 

GO 

GO to 

switch 

SW 

SWitch 

do 

DO 

DO 

array 

RY 

aRraY 

return 

RE 

REturn 

comment 

CM 

CoMment 

stop 

SP 

StoP 

integer 

# 


for 

FR 

FoR 

boolean 

BO 

BOolean 

or if 

OR 

OR if 

complex 

cx 

Complex 

if either 

IE 

If Either 

double pr 

DP 

Double Precision 


Fig. 3.16 Mnemonic derivations for characters 

Other words could be assigned to single graphics: 

COMMENT could be assigned to " 

STOP could be assigned to ! 

RETURN could be assigned to <— 

Record Mark ^ and Group Mark 4 s were assigned to 'existing hole 
patterns 0-8-2 and 12-8-5, respectively. The mnemonics chosen, SY and ! 
EH, are not of course mnemonics for Record Mark and Group Mark, but 
are mnemonics for the appropriate hole patterns for keypunching: 

S, 0-2 Y, 0-8 SY, 0-8-2 

E, 12-5 H, 12-8 EH, 12-8-5 



Exclamation Point 
QUote 


Double Quote 
I Left Substitution 


( Right Substitution 
base TeN 


| Right Bracket 

I Left Parenthesis 



w 

Up arroW 

w 

I Down arroW 


j Left arroW 
Right arroW 


I BeGin 
| eND 



* 

Y 1 

SWitch 

aRraY 

mm 

w 

, CoMment 




signed to existing hole 
:monics chosen, SY and 
rk id Group Mark, but 
fo. keypunching: 



ggggQQDBDDDDDDDD 


TL - Transmit Leader 
CL - Control Leader 
S0R1 - Start of Record Odd 
ACK1 - Acknowledge Odd 
S0R2 - Start of Record Even 
ACK2 - Acknowledge Even 


INQ - Inquiry 
ERR - Error 
IDLE - Idle 
*TEL - Telephone 

*EOT - End of Transmission/Message 

* May be sent as valid 
data characters 


Fig. 3.17 4-OUt-Of-8 code data characters 

3.8 4-OUT-OF-8 CODE 

Another code of the early 1960s had an interesting characteristic. It was 
used solely for data transmission; it was an 8-bit code. The interesting 
characteristic was that, of the 8 possible bit positions for any bit pattern 
of the code, exactly four of the bits would be one-bits. Hence the name, 
4-out-of-8 code (see Fig. 3.17). Any single “hit” (the accidental change of 
a zero-bit to a one-bit, or of a one-bit to a zero-bit) on a bit of a 
transmitted bit pattern would create an other than 4-out-of-8 bit pattern, 
and such erroneous bit patterns could be checked by very simple circuitry. 
Each bit pattern, as received, was fed through a counter. If the count was 
4, the bit pattern was accepted as valid, otherwise a data check was 
raised. Of course, compensating hits (that is to say, hits on a single bit 
pattern that changed some one-bit to a zero-bit and some zero-bit to a 
one-bit) would not be detected, but occurrence of such hits was statisti- 
cally very much less than occurrence of single bit hits. 


?; t 
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Mathematically, the code allows exactly 70 valid 4-out-of-8 bii 
patterns. As can be seen by examination of Fig. 3.17, 64 of these wer 
graphic characters (called “data characters” at that time) and 6 wer 
control characters. Thus this code fittted BCDIC nicely with its 6 
characters. As will be described in Chapter 5, 7 of the 64 characters o 
BCDIC were control characters between various BCDIC CPU’s an 
magnetic tape drives. However, these 7 BCDIC control characters wer 
not 4-out-of-8 control characters; that is to say, they would be transmit 
ted, end to end, without effecting any control actions on the dat 
transmission units. 

Some of the 4-out-of-8 control characters did double duty, depend 
ing on the data transmission situation. Thus a data transmission unit 
sending a data record, would precede it with SOR1, Start of Record Odd 
When the transmission unit at the other end received this record, it woul 
send back to the original transmission unit ACK1, Acknowledge Od 
(providing no data check had been detected by the receiving unit). 

Note from Fig. 3.17 that although the numerics and alphabetics ar 
not contiguous within columns, they are nevertheless BCD, under th 
definitions in Chapter 2. 


P 
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4 

The Duals 
of 

BCDIC 


The code described in the previous chapter as “early BCDIC” will be 
called BCDIC, Version 1 in this chapter. This coded character set was 
extended; first by the addition of duals, to BCDIC, Version 2, and then by 
an expansion to 64 characters, to BCDIC, Version 3. 

4.1 BCDIC, VERSION 1 

In the late 1950s, the chain printers provided by IBM had a printing 
repertoire of 48 graphic characters, as follows: 

Space 1 

Alphabetics: A to Z 26 

Numerics: 0 to 9 10 

Specials: 

Dollar sign $ 

Slash / 

Lozenge ct 

Asterisk * 

Percent sign % 

At sign @ ii 

Ampersand & 

Minus, Hyphen — 

Number sign # 

Period 

Comma 
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» j B ’ rpjm ; ■ 



Fig. 4.1 BCDIC, Version 1 

These 48 graphic characters were also keypunchable, interpretable, and 
verifiable by a single keystroke on the IBM keypunches and verifiers of 
the day. These 48 characters, which constituted BCDIC, Version 1, are 
shown in Fig. 4.1 

4.2 BCDIC, VERSION 2 

Two data processing requirements, European languages and FORTRAN 
led to the development of what came to be called “duals.” 


4.2.1 European Languages Requirements 

The languages of some European countries (Germany, Sweden, Den- 
mark, Norway, Finland) require 29 letters — the usual 26 alphabetics of 
English-speaking countries plus three letters called diacritics. Spanish and 
Portuguese alphabets have 27 letters. It would be clearly advantageous 
from a marketing point of view, to be able to provide these extra! 
alphabetics on printers, keypunches, and verifiers. But how could this be? 
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done? The solution that was examined first was to increase the character 
capability of printers, keypunches, and verifiers from 48 to 51. 

In the case of chain printers, this was entirely feasible, since the chain 
has a possible graphic capability of 240. In fact, on 48-character chains, 
each of the 48 graphics appears five times on the 240-graphic chain. If 
there are more than 48 graphics, 51, for example, some of these graphics 
will not appear five times on the chain; in consequence, the printing speed 
(lines per minute) would be reduced. Since printing speed was (and is) a 
primary competitive factor for printers, the solution of providing 51 
graphics on a chain, with consequent slower printing speeds, was unat- 
tractive. 

In the case of the keypunch (and verifier), two approaches were 
examined. Under the first approach, card hole patterns beyond the 48 
could be assigned and keypunched by the technique known as multi- 
punching. Under this technique, while a “multipunch” key is held down, 
other keys may be struck, but the punched card does not advance to the 
next card column. Accordingly, a number of holes may be punched in a 
single card column. Clearly, when any of the three diacritic letters is 
encountered on a data sheet by a keypunch operator, the keypunching 
mode would have to depart from touch-keying while the operator pays 
special attention to holding down the multipunch key and to keying such 
other keys as necessary to generate the appropriate hole pattern. In this 
approach, then, the keypunching speed would be reduced. As with the 
line-printer solution discussed above, this approach to keypunching was 
unattractive. 

Under the second approach, either existing keypunches and verifiers 
could be modified, or new keypunches and verifiers could be designed 
with additional keys to generate each of the three diacritics with a single 
keystroke. Presumably (after some training) keypunch operators would be 
able to touch-key the additional keys, so keypunching speed would be 
maintained. This approach would result in a relatively costly design and 
development project, with a product that would have only a small market. 
The projected additional price for European keypunches and verifiers was 
unattractive. 

A different kind of solution was then proposed. It was observed that 
three special graphics @ # $ were peculiar in origin and use to English- 
speaking countries. They were neither needed nor used at that time in 
continental European countries. The suggestion was to substitute the three 
diacritics for these three specials, wherever they appeared on the chain. 
The consequence was that printing speed would not be reduced. Simi- 
larly, they could be substituted on the keytops and printing plates of 
keypunches. 
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Under this substitution approach, only minor costs would be in 
volved. The solution, then, had the following characteristics: 

No reduction in printing speeds. 

No reduction in keypunching/verifying speeds. 

Small cost. 

This approach had the advantages above, and no (known) disadvantages 
It was adopted. The approach is still used in current products. 

It should be noted, in respect to this approach, that there results ' 
number of graphics— multiple graphics, that is— for three card hoi. 
patterns, as shown in Fig. 4.2. However, within a country, the graphic se 
is unique, without duals. 


Hole pattern 

U.S.A. 

Germany 

Sweden 

Finland 

Norway 

Denmark^ 

8-3 

# 

A 

A 

A 

£. 

9 

£. '* 

8-4 

@ 

6 

6 

6 

0 

0 4 

11-8-3 

S 

0 

A 

A 

A 

A 


Fig. 4.2 Diacritic letters 


4.2.2 FORTRAN Requirements 

The FORTRAN programming language had, among its other objectives! 
the objective of a printed listing that would resemble as much as possible 
the formulae found in mathematical text books. Many of the mathematil 
cal symbols found in text books were deemed to be unnecessary foa 
FORTRAN. Some mathematical symbols / - . , were already provide! 
on IBM printers. It was decided that the asterisk * could be used tJj 
represent multiplication. But five symbols ( ) + = ' (not provided onj 
IBM printers) were deemed to be absolutely necessary for FORTRAN! 
How to provide them? 

It was decided that the most economical and efficient solution was tc 
provide them by substitution, as with the European diacritics. The only 
remaining problem was to choose which five of the specials provided on 
IBM 48-character printers, keypunches, and verifiers should be replaced 
by the five mathematical symbols. It was decided to replace % tt & # 
b y ( ) + = ' (respectively). This solution resulted in duals within a’ 
country. The addition of these five duals led to BCDIC, Version 2, shown 
in Fig. 4.3. .ijj 




Hole Patterns: 

DU 3-2 

m 0-8-2 


Fig. 4.3 BCDIC, Version 2 

Initially, this solution was ideal. With very few exceptions, computing 
installations in those days were either of a commercial orientation or of a 
scientific/engineering orientation. In “commercial” installations, such 
commercial applications as payroll, inventory, premium billing, and utility 
billing were processed; in such installations, neither scientific nor en- 
gineering applications were processed. Similarly, in “scientific” installa- 
tions, scientific or engineering calculations were processed, and commer- 
cial applications were not. (I repeat, there were few exceptions.) 

The exceptions that began to be noted were those users who had 
installations that were commercially oriented, although the company itself 
was of an engineering or scientific nature. In such companies, there were 
people who wanted to use the computer for scientific or engineering 
calculations. It is to be noted that the processes of compiling, debugging, 
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cornmereml graphic sets. However, if the installation had the commer C i° 

—• ** 

x = (A + B) * (C - D)/(E + F * G) 
would show in the program listing as 

X#%A&Bh*%C— Dh/%e&F*G H 

Such program listings, though bizarre, were unambiguous To FOR* 

ed in the — * s 


1 


1 


| 


& to + 

# to = 

@ to ' 

became an automatic act. 

wer/nfeded or ^ Sdentific s y mbols seldom (if ever 

needed or used m the listings that were the final results of th 

executed programs. It was only in the listings of the original FORtL 

P ograms that programmers had to put up with the graphk substVtm^ns 

Programmers were (and, incidentally, still are) notabfy vocal If there 

ere something to complain about, they complained vociferously These 

complaints gav e rise to the question. Could this situation admSS 

frequent but nonetheless aggravating, be ameliorated? 

4.3 BCDIC, VERSION 3 - ] 

tAnotff* 011 tt° t ^ 16 C * Ua * s P r °bl em ” was attempted with the IBM 1410 

in the ^ Stem / 36 0- See Chapter 9 Z DuL 

IC) 1410 W3S t0 have as its “"sole, a typewriter Th 
typewriter could provide up to 88 graphics. It was dedded it WO ul 

L VI , h 63 ’ if n 1 Space. (The reasons for a character set size of 64 are’ 
tailed m the following chapter. The Size of BCDIC.) The 47 graD hi 
and Space provided on 48-character chain printers are showntn ^4 3 

t JJ® 63 . g phlCS and s P ace P r °Posed to be provided on the 1410 consol 
typewriter are shown m Fig. 4.4; it is called BCDIC, Version 3 

graphics') ?-*£??? ** * A that four ot ,he *» “scientific 1 
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Hole Pattern*: 

CD 8-2 

CD 0-8-2 

Fig. 4.4 BCDIC, Version 3 

fifth scientific graphic + was not to be provided. The author does not 
know the reason for this curious anomaly. 

Beyond the four scientific graphics. 12 new graphics had been added. 
These were of two kinds: 

Kind 1 ^ 

Kind 2 =j= V A + 


The graphics of Kind 1 were added as a result of market studies for 
most-needed graphics” in data processing applications. The graphics of 
Kind 2 were chosen to meet a criterion which will be described in the 
next chapter. 

This coded character set was announced for the IBM 1410. How- 
ever, as will be discussed in the next chapter, a review of coded character 
sets was then undertaken, and this led to the BCD Interchange Code 
BCDIC. ’ 
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Graphic Subsets 
for the 
Government 


22.1 A AND H SUBSETS 

As described in Chapters 4, 9, and 10, there were various subsets of 
BCDIC and of EBCDIC. The most popular of these, the A and H sets, 
manifested themselves on 48-character trains/chains. 


BCDIC 

EBCDIC 

A to Z 
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0 to 9 
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A-Set 

H-Set 


A-Set 

H-Set 



Total 

47 


Total 

48 
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It is to be noted that the BCDIC subsets shown above are actually 
47-graphic sets. The 48th graphic on the chain/train was sometimes 4= , 
sometimes - (repeated), sometimes a company logo, and sometimes 
something else. 

In fact, there were quite a number of 48-graphic trains/chains 
available. Consider, then, the problem of a computing installation that 
received from some source outside the installation a report to be listed. 
This report might come to the installation on punched cards or on 
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magnetic tape. If the source installation had prepared the report using air 
A-train and if the receiver installation used an H-train to list the report,- 
there would be some unintelligibility in the listing, the amount depending! 
on the extent to which the source installation had used special graphics^ 
beyond the period, comma, slash, asterisk, minus sign, and dollar sign. A 
This kind of confusion was compounded where many installations J| 
sent data from one to another to be listed and where a variety off 
48-graphic trains/chains were used in the installations. An obvious solu-S 
tion to such situations would have been for somebody in authority over 
all the installations to issue an edict to all installations to always use the ■ 
same train/chain. r^p 

Such a simplistic solution would probably not have worked very welT 
in real life. Installations had particular trains/chains for a particular? 
reason, and users would have resisted the bureaucratic order to changes 

22.2 DEPARTMENT OF DEFENSE SOLUTION 

During the early 1960s, a different kind of solution was tried in tfil 
Department of Defense. Recognizing that 42 graphics — 26 alphabetic^ 
10 numerics, and 6 specials (period, comma, slash, asterisk, minus signal 
and dollar sign)— were common to all trains/chains, an edict was issuecy 
that only these 42 graphics could be used on reports. (Incidentally, it was| 
exactly this set of 42 characters, together with the Space character, that! 
formed the “hard core 43” described in Chapter 17. 

This solution had moderate success. A countervailing factor was that 
military part numbers used the left parenthesis, the right parenthesis, and 
the number sign, and part numbers were in much of the report data! 
interchanged between military installations. 


22.3 FIPS PUB 15 SOLUTION 

In the late 1960s, a Federal Information Processing Standards Publication 
(FIPS PUB) 15 was approved. FIPS PUB 15 stated that “all applicable 
equipment ordered on or after the date of this FIPS PUB must be 
conformance with this standard . . .”. 

“Applicable equipment” included printers, display devices, punched^ 
card equipment, and other data processing or communications equipment 
The standard specified three graphic subsets: 

■ a 16-character graphic subset, 

■ a 64-character graphic subset, 

■ a 95-character graphic subset. 

The graphic subsets were derived from ASCII, shown in Fig. 22.1. J 
The 16-graphic subset consisted of the 10 numerics and 6 specials 
column 3 of the code table. 
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22.4 FIPS PUB 15 TRADE-OFF 

The federal government had made an interesting trade off here 
described in Chapter 10, the nominal printing speeds (LPM, lines pri 
per minute) for train/chain printers, depending on the number of grar 
in the repeated sets of the train/chain, were as follows: 

Number of graphics Repeated sets Nominal printina soeed 


w 6 1250 LPM 

2 5 noo lpm :m 

60 4 950 LPM 

120 2 570 LPM 

240 1 300 LPM 

The number 64 does not divide evenly into 240, so for a 64 (really 7 ^' 
plus Space) graphic set, the “preferred” graphic approach would have tt 
be used. For the 64-graphic subset, the nominal printing speed would bi 
approximately 940 LPM. Assume, for the purposes of discussion, thatthi 
train/chain printer would run without stopping for 8 hours Then tlu 
48-graphtc printer would produce 528,000 lines of print, wherea* 
64-graphic printer would produce approximately 451,000 lines of print 
that is, approximately 77,000 lines of print less during 8 hours. ^iSf! 

The federal government was making a trade-off between producti 
ity of lines printed and intelligibility of interchanged data as printed !§9 
FIPS PUB 15 did recognize that the bulk of printing in an instil 
tion would probably not come from data interchanged from another 
installation, and that productivity of printed lines for such noninte^ 
changed data should not be reduced. FIPS PUB states: 

Printers of the chain” or “train” or other replaceable symbol 
technology must be provided with the ability to conform to one of 
the subsets herein but may also be provided with optional subsetsf 
having a different number of characters than those specified herein J| 
order to increase either the printer repertoire of symbols o||8ji 
printer speed in local use. '"'Egfll 

That is to say, federal departments and agencies could order 48-charactl| 
train/chain printers, as long as a 64-character train/chain could be 
mounted if needed. And that is an easy and simple thing to do with 
train/chain printers. .jaH 
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Which ASCII? 


23.1 ASCII-1963 

A national standard, even when approved, may nevertheless not remain 
fixed and unchanging. When ASCII became an approved American 
standard in 1963, it was not complete. As may be seen from Fig. 23.1, 28 
code positions in columns 6 and 7 were not filled. In addition, the control 
character in position 0/8 was defined very broadly as a “format effector” 
(in contrast with the other “format effectors” Horizontal Tab, Line Feed, 
Vertical Tab, Form Feed, and Carriage Return that were defined very 
specifically), and the control characters in positions 0/8 through 015 were 
broadly called “separators.” 


23.2 ASCII-1965 

As can be seen from Fig. 23.2, ASCII in 1965 was changed from 
ASCII-1963. Some of these changes, such as the addition of small 
alphabetics in columns 6 and 7, the change of name without change of 
essential meaning of some control characters — Start of Message (SOM) 
changed to Start of Header (SOH); End of Message (EOM) changed to 
End of Text (ETX) — can be described as evolutionary, in that they did 
not change what existed before, but simply added to it. 

Other changes, such as moving Escape (ESC) from position 7/14 to 
position 1/11; “...Are you?” (RU) in position 1/6 being replaced by 
Acknowledge (ACK); changing \ f and *— to " * and _in positions 5/12, 
5/14, and 5/15, respectively, can be described as revolutionary, in that 
they did change what existed before. 
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NULL 


As described in Chapter 16, a proposed American national stan^ 
which specified a card code radically different from the well-establish< 
Hollerith Card Code was resolutely voted down at X3 by users wl 
clearly foresaw the substantial economic impact of such a revohitiona 
change. As described in Chapter 21, a draft ISO standard that specified 
change to well-established card hole patterns for alphabetic extenders w 
approved, but has not been implemented — again because of the econonj 
impact on users. 
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Fig. 23.2 ASCII-1965 
23.3 ECONOMIC IMPACTS 

It is reasonable to inquire, therefore, whether changes to ASCII, such as 
those described above, have had similar economic impacts. Two examples, 
to be described below, will give insight on this question. (Both these 
examples are drawn from the author’s experience.) However, the follow- 
ing explanation must preface the examples. 

Reference was made above, and will be made below, to ASCII- 
1965. Some rather unusual circumstances surround ASCII-1965. ASCII- 
1963 had been approved and published in June 1963. Since that time, the 
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American subcommittee X3.2 (now X3L2) had been working to com- 
plete the code table. There was considerable interplay between the I 
American subcommittee and the ISO subcommittee ISO/TC97/SC2 I 


(which will be referred to in the remainder of this chapter as SC2). SC2 i 


was working on the ISO Draft Proposal for a 7-Bit Code. The two 
subcommittees, X3.2 and SC2, were striving to achieve compatible 7-bit A 


codes. Some graphics, and some controls, were under contention and 


controversy. 

By January of 1965. X3.2 had completed its “revision” of ASCII and §|| 
forwarded it to X3 for further processing. During the X3 balloting, a •' 
controversy arose with respect to graphics for Logical OR and Logical 
NOT (see Chapter 24). This controversy delayed further processing of the 
revised ASCII at that time. "'^^0^' 

Meanwhile X3.2 had received information that, at the upco ming Bp 
April 1966 meeting of SC2, changes would be made to the ISO Draft M 
Proposal. These changes would create incompatibilities between the ISO ' ' 

7-Bit Code and ASCII. ’■wBEBk 


Therefore, X3.2 requested X3 to request ASA to delay publication^! 
of the revised ASCII until after the SC2 meeting. This request was 3 
granted and ASCII-1965, although approved by ASA, was, in fact, never"! 
published or distributed. 


23.4 THE 2260 DISPLAY STATION 

IBM’s first ASCII transmission product, the 2260 Display Station and 
2848 Display Control, announced in 1965, was based on ASCII-1965- fiJ&A 


As can be seen from Fig. 23.3, not every character of ASCII-1965 was*ja| 
implemented. Eight control characters (sufficient for the data communica- 3 
tions protocols of the day), the Space character, and 59 graphic characters 
were implemented. These 59 graphics, shown below, were the graphic set 
of the programming language PL/I: 


26 capital letters 
3 alphabetic extenders 
10 numerics 
20 syntactics 


A to Z 

# $ ( 
0 to 9 

( ) < 


The symbols shown below the code table of Fig. 23.3 had the/ 
following meanings: r '3§S 


displays on the 2260 Display as ■ (End of Message symbol). Prints,; 
on 1053 Printer as ! (exclamation mark). TidjM 

2 Displays on the 2260 Display as ■ (Check symbol). Prints on the., 
1053 Printer as “ (quotation marks). 
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23.5 THE 1053 PRINTER 

It is to be noted, then, that 62 graphics were printable on the 105^ 
Printer. The 1053 Printer was a typewriter-based product with a printing 
capability of 88 graphics. However, the capital letters were duplicated, | 
that is, they printed whether the typewriter was in upper-case or lower-1 
case shift. Accordingly, 88-26 = 62. 

23.6 ASCII-1967 

The standards committee X3.2 continued with its work to arrive at an 
agreed-upon ASCII, and ASCII-1967 was the result. 

23.7 ASCII-1965 VERSUS ASCII-1967 

A comparison of ASCII-1965 (Fig. 23.2) and ASCII-1967 (Fig. 23.1)5 
shows changes in 6 code positions: 


Code position 

ASCII-1965 

ASCII-1967 

1/10 

SS 

SUB 

4/0 


<& 

5/12 

- 

\ 

6/0 

@ 


7/12 

- 

1 

7/14 

i 



23.8 THE 2265 DISPLAY STATION 

The changes in code positions 1/10 and 5/12 do not affect the discussion! 
in this chapter, since they had not been implemented on the 2260. But’at 
follow-on product to the 2260, the 2265 Display Station and 2845 
Display Control, was being developed, and the pertinent question was 

Should the 2265 be compatible with the 2260 and hence in noncon- 
formance to ASCII-1967, or should the 2265 be in conformance to/ 
ASCII-1967 and hence incompatible with the 2260? v||| 

Since the 2265 was planned to replace installed 2600’s, compatibility: was; 
a requirement. The question then became “Which was more important^ 
compatibility or conformance?” In the end, it was decided that compati-g 
bility was more inportant. The nonconformance to ASCII-1967 ( bj|| 
conformance to ASCII-1965) was carefully explained in the 22(jg| 
manuals. 

A dilemma of a different kind was posed because of an incorrecft 
guess on the ultimate shape of a draft standard. Before discussing ''tiMS 
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Logical OR, 

Logical NOT 



24.1 ASCII-1963 

When ASCII became an approved American National Standard in 1963, 
it was not complete. There were 28 code positions in columns 6 and 7 
that had no assigned meaning. There was some controversy on whether 
small alphabetics or additional control characters should be assigned to 
these positions. This controversy was resolved when, at the 1963 October 
meeting of ISO/TC97/SC2, it was decided to assign small alphabetics in 
the ISO 7-Bit Code then being developed. 

24.2 ASCII-1965 

By January 1965, X3.2 had completed work on the Proposed Revised 
ASCII, which was compatible with the ISO 7-Bit Code. The code table is 
shown in Fig. 24.1. 

24.3 PL/I 

In this code table, a problem was perceived with respect to PL/I, the new 
programming language which had been announced with the System/360 
in April 1964. The graphics of PL/I were of five kinds: 

1 space 

10 numerics 0 to 9 
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Fig. 24.1 ASCII-1965 

The term syntactic meant that the programming language would assign 
some specific function to a graphic when that graphic was used in a 
programming language source statement. For example, 

* would mean multiplication, 

/ would mean division, 

& would mean Logical AND, 

| would mean Logical OR, 

would mean Logical NOT. 
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Ground Rules 


24.4 THE PROBLEM 

The problem that was perceived was based on the assumption that, some 
dav. PL/I would become a candidate for international standardization. 
(That assumption turned out to be correct.) At that time, among the 
many aspects of PL/I that would be reviewed would be the character set. 
Presumably, the committee would agree on the 29 alphabetic, 10 
numeric, and 20 syntactic functions, but they might well debate the actual 
graphics to be associated with the syntactic functions. For example, is ^ 
the appropriate graphic to be associated with the syntactic function of 
"Logical NOT"? 

A further assumption was made, which was that the committee 
would set two ground rules with respect to the graphic character set of 
PL/I. 

24.5 GROUND RULES 

Ground rule 1 

All graphics for the PL/I character set would be chosen from the set of 63 
graphics in the center four columns of the ISO 7-Bit Code. 

Ground rule 2 

The graphics associated with the syntactic of PL/I should not be as- 
sociated with a code position reserved in the ISO 7-Bit Code for 
alphabetic extenders. 

The reasoning behind these ground rules was as follows. For Ground 
rule 1, it was the judgment of many people at that time that most 
upcoming printing and display devices would have a repertoire of 63 
graphics and Space. The 63 graphics, in fact, would be those in columns 
2, 3, 4, and 5 (the center four columns) of the 7-Bit Code. For Ground 
rule 2, although alphabetic extender code positions might have graphics 
like [ ] and \ in English-speaking countries, in Germany and the four 
Scandinavian countries, alphabetics would indeed be in those positions. 
Therefore, no matter how appealing a graphic in an alphabetic extender 
position of the code for English-speaking countries might be, it could not 
be used as a syntactic for any programming language. 

As can be seen from Fig. 24.1, three of the PL/I graphics, @ | and , 
were not in the center four columns (Ground rule 1), and also " and |, 
PL/I syntactics, were in alphabetic extender positions (Ground rule 2). 

The reason for @ being in code position 6/0 is interesting. It was 
forecast that, in the French national variant of the ISO 7-Bit Code, @ 
would be replaced by a. Since a is an accented small letter, it should be in 
columns 6 or 7 where the other small alphabetics were positioned. With 
the U.S.A. requesting that (a> be in code position 4/0, and with France 
requesting that it be in 6/0, it actually moved back and forth at successive 
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meetings of ISO/TC97/SC2. Ultimately, it was agreed to position it 

4/0 and thus this part of the PL/I graphic set problem resolved itself 
satisfactorily. 

The problem with | (Logical OR) and “■ (Logical NOT) 

Lser groups SHARE, GUIDE, and COMMON, becoming aware of 
problem, became concerned. Letters were written from various com- 
panies in these user groups to the Chairman of X3 requesting that the 
problem be solved. Representatives from these user groups attended 
Xj. 2 meetings and X3 meetings to lobby for their requirement. 
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Various proposals were made to solve the problem. For example, it 
was proposed that | and replace ! and ", respectively, in the code table. 
All such proposals to change the set of graphics in the ASCII code table 
were rejected by a majority of the X3.2 members. X3.2 completed its 
work on the draft Proposed Revised ASCII and forwarded it to X3. 

On the X3 letter ballot, the Joint Users Group (which included 
SHARE and COMMON among its members) voted no. A sufficient 
majority of X3 affirmative votes was received, however, and the draft 
standard was forwarded to ASA. In December 1965, the Information 
Processing Standards Board of ASA approved the Revised ASCII. 

In January 1966, X3.2 received information that changes would be 
made to the 4th Draft ISO Proposal for (6 and) 7-Bit Codes. These 
changes would not speak to the Logical OR/Logical NOT problem; they 
would be with respect to some control characters. The consequence 
would be that ASCII would then be incompatible to the ISO 7-Bit Code. 
Therefore, X3.2 requested X3 to request ASA to delay publication of the 
revised ASCII until after the April 1966 meeting of ISO/TC97/SC2. This 
request was granted. In fact, ASCII-1965, although approved by ASA, 
never was published. 

Changes were indeed made to the ISO 7-Bit Code at the April 1966 
meeting. The SS (Start of Special) character in position 1/10 was replaced 
by SUB (Substitute); @ and ' flip-flopped again, @ ending up in 4/0 and ' 
in 6/0; ? replaced ~ in position 5/12; | was moved from 7/14 to 7/12; and “ 
(overline, or tilde) was placed in 7/14. This was the final version of the 
ISO 7-Bit Code. It became an approved ISO Recommendation, R646, in 
1967 (see Fig. 24.2). 

The Logical OR/Logical NOT problem was discussed at this meeting 
and a solution (of sorts) was set into the document. (This solution will be 
described later in this chapter.) 

24.6 REVISED ASCII 

ASCII itself now had to be revised to bring it into line with the changes 
made to the ISO 7-Bit Code. Once again, a draft Proposed Revised 
ASCII was under preparation by X3.2. The Logical OR/Logical NOT 
problem continued to concern X3.2. 


24.7 THE SOLUTION FOR ASCII 

Ultimately a solution was found. The solution has two parts. The first part 
is the inclusion of the following text in Section 6.4 of the ASCII standard: 


No specific meaning is prescribed for any of the graphics in the code 
table except that which is understood by the users. Furthermore, this 
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standard does not specify a type style for the printing or display of 
the various graphic characters. In specific applications, it may be 
desirable to employ distinctive styling of individual graphics to facili- 
tate their use for specific purposes as, for example, to stylize the 
graphics in code positions 2/1 and 5/14 into those frequently as- 
sociated with Logical OR | and Logical NOT ”, respectively. 


This text was taken to mean that manufacturers could, if they wished 
substitute the graphics | for !, and ” for \ 


24.8 THE SOLUTION FOR THE ISO 7-BIT CODE 




It should be pointed out that positioning the Logical NOT graphic in 
position 5/14 does not strictly satisfy Ground rule 2, since position 5/14 is 
an alphabetic extender position. However, the 10 positions designated as 
alphabetic extender positions in the ISO 7-Bit Code are viewed as being 
divided into “primary” and “secondary” by virtue of the footnotes which 
speak to them. For the 7 “primary” positions, 4/0, 5/11, 5/12, 7/11, 7/12, 
7/13, the footnote reads (in part): 


Reserved for National Use. These positions are primarily intended 
for alphabetic extensions. If they are not required for that purpose, 
they may be used for symbols . . . 


By contrast, for the 3 “secondary” positions, 5/14, 6/0, and 7/14, the 


footnote reads (in part): 



Positions 5/14, 6/0, and 7/14 . . . are normally provided for the 
diacritical signs “circumflex,” “grave accent,” and “overline.” How- | 
ever, these positions may be used for other graphical symbols when it 
is necessary to have 8, 9, or 10 positions for national use. 

It was reckoned that, in Germany and in the four Scandinavian countries 

wherp thp T noirn I flR/T 1 MOT' r-»r*/-\Kl uiakM *-U ~ 


where the Logical OR/Logical NOT problems would exist, these three -J 
“secondary” positions would not be needed for national use, so Ground vlllte 


positions would not be needed for national use, 
rule 2 would not really apply to these code positions. 

The second part of the solution had to do with the graphic | (Vertical :i 
Line) in code position 7/12 (Fig. 24.2). Suppose a manufacturer im- 
plemented | (Logical OR) in code position 2/1, as permitted by Section 
6.4 of the ASCII standard. These two graphics, as printed or displayed, >• 
would be indistinguishable to the human eye. The solution to this 
problem was to change the actual graphic in position 7/12 slightly. It |§L 
became | (still called Vertical Line) but now clearly distinguishable from j A “ ' 
(Logical OR). 
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As an interesting sidelight, IBM had previously called the graphic | 
Logical OR or Vertical Bar in its internal EBCDIC standard and in 
reference manuals. From this point in time, IBM called it Logical OR, to 
avoid confusion in nomenclature. 

The “solution” previously mentioned for the ISO 7-Bit Code was the 
following text in Section 4.3 of ISO R-646: 

4.3 Interpretation of graphics 

The meaning of the graphics is not defined by this ISO Recommen- 
dation. It will be necessary to reach agreement on the meaning and 
this will depend upon the particular application except in cases where 
other ISO Recommendations already exist. However no interpreta- 
tion may be chosen which is contradictory to the customary meaning. 
A graphical symbol can have more than one meaning, e.g., the 
graphical symbol - (minus) also can have the meaning of hyphen or 
separation mark. The font design of the symbol is not part of this 
ISO Recommendation. 

It is to be noted that, in contrast to the explicit solution in ASCII, this is 
an implicit solution based on the following point. The last sentence of 
Section 4.3 leaves the question of “font design” open; that is, a manufac- 
turer could design ! to look like | and ' to look like A 

The Logical OR/Logical NOT problem had finally been solved. 
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